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(57) Abstract: A system for communication between a first computer terminal (1) in a private IP network (7) and a second computer 
terminal (5) in a public IP network, comprising network frontier equipment (3). According to the invention, the communication 
system also comprises a mediating system (2), which is associated with the first terminal (1) and which can provide an IP interface 
^| to the second terminal (5), in the private IP network, and a control server (4), which is used to control the mediating system (2) via 
a communication tunnel crossing through the network frontier equipment (3), in the public IP network. The invention can be used 
with IP communications between public and private networks. 
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(57) Abrege : Systeme de communication cntrc un premier terminal informatique (1) dans un nSscau IP prive* (7) et un deuxieme 
terminal informatique (5) dans un reseau IP public, comprenant un equipement (3) de frontiere de r€seau. Selon 1'invention, ledit 
systeme de communication comprend 6galement, dans le r£seau IP prive\ un systeme (2) de mediation, associe audit premier terminal 
(1), apte a mettre a disposition dudit deuxieme terminal (5) une interface IP, et, dans le rSseau IP public, un serveur (4) de contrflle 
apte a controler ledit systeme (2) de mediation via un tunnel (6) de communication travcrsant ledit equipement (3) de frontiere de 
reseau. Application aux communications IP entre r£seaux publics et reseaux prives. 
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SYSTEME DE COMMUNICATION ENTRE RESEAUX IP PRIVES ET 

PUBLICS 

la presente invention conceme un systeme de communication entre un 

premier terminal informatique dans un reseau IP prive et un deuxieme 

terminal informatique dans un r6seau IP public. 

D'une maniere genSrale, I'invention trouve une application 
5 particulferement avantageuse dans le domaine des communications IP entre 

reseaux publics et r6seaux priv6s, et plus sp6cialement quand un rSseau IP 

public doit communiquer avec un reseau IP priv6. 

Afin de remSdier au nombre limite d'adresses IP dans la version 4, 

PI AN A (Internet Assigned Number Authority) a normalise la notion de reseaux 
10 priv£s et d'adresses privees dans la RFC (Request For Command) 1918. Ces 

adresses privies, affectees dans des plages particulferes, ne sont pas 

routables par les routeurs du r§seau public, comme I' Internet par exemple. 

Cette solution permet de raccorder un grand nombre de terminaux 

informatiques dans un* meme r6seau priv6. 
15 Les terminaux de ce reseau qui ont besoin de dialoguer avec d'autres 

9 

terminaux informatiques du reseau public doivent passer par des Squipements 
de frontiere de reseau. Certains de ces Squipements sont connus sous le nom 
de passerelles (ou « gateway » en terminologie angb-saxonne). Les 
passerelles ont une adresse IP du r§seau public et une adresse IP du r6seau 

20 prive. Elles sont mandataires des terminaux du reseau priv6 pour leurs 
requetes vers le reseau public. Elles re?oivent les requites d'un terminal priv6 
via leur adresse IP privee et reformulent ces requites sur le reseau public en 
utilisant leur adresse IP publique. La reponse a cette requete arrive £ la 
passerelle qui la retransmet au terminal du reseau priv6 ayantfait la requete 

25 en utilisant Tadresse priv6e. Ce mecanisme nomme NAT (Network Address 
Translation) est normalis6 dans la RFC 3022. 

Associes a ces passerelles, d'autres equipements de frontiere de reseau 
appeles pare-feu (ou « firewall » en terminologie anglo-saxonne) sont des 
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entites de securite qui permettent de controler facets de et vers r Internet. 
Ces pare-feu font I'objet de regies plus ou moins restrictives. 

II existe pour certains types ^applications des Elements appetes agents 
de proximite (ou « proxy » en terminologie anglo-saxonne). Ces agents de 
5 proximite sont des mandataires spScifiques d des protocoles particuliers, les 
plus cpnnus etant les proxys HTTP et FTP (File Transfer Protocol), lis 
re9oivent les requ&es des terminaux du r6seau priv6 et font la requete en leur 
nom sur le reseau public, lis peuvent etre dispos6s derriere des passerelles. 
Etant des points de passage oblige des communications d'un protocole 

10 donnS, on leur a ajoute des services particuliers comme le mecanisme de 
cache pour les agents de proximite du protocole http. 

Une des caracteristiques principals du m§canisme NAT est qu'il est 
asym&rique. Un paquet IP peut passer librement du reseau prive vers le 
r6seau public. Par centre, un paquet ne peut passer du r6seau public vers le 

15 r6seau prive que si un paquet a fait le chemin inverse. Ce qui implique qu'un 
terminal du r6seau prive doit etre £ 1'initiative de toute communication. 

Le mecanisme sous-jacent est bas§ sur la notion de route. Une route, 
pour un §quipement effectuant une operation NAT, est un triplet de couples 
« adresse IP-port ». Quand un paquet arrive sur I'equipement de frontfere de 

20 r6seau venant du reseau prive, cet 6quipement enregistre le couple « adresse 
IP-port » du terminal informatique du reseau prive qui a emis le paquet, ce 
couple sera nomm6 couple! Le couple « adresse IP-port » de destination 
dans le r6seau public sera appele couple2 t de meme que le couple « adresse 
IP-port » de 1'interface publique de I'equipement de frontfere de reseau, par 

25 lequel le paquet va §tre envoy 6, sera nomm6 couple3. Si un paquet arrive sur 
Pinterface publique venant du reseau public, I'equipement de fronttere de 
reseau cherche une route correspondante, e'est § dire celle dont la source 
correspond a un couple2 et la destination & un couple3 d'une route 
prSalablement elue. Si une telle route existe, le paquet sera alors transmis 

30 vers le couplel de la route elue. SMI n'existe pas de route elue, le paquet n'est 
pas transmis sur le reseau prive. Ainsi, un paquet arrivant du reseau public ne 
pourra etre transmis sur le r§seau prive que si un paquet du reseau priv6 lui a 
prealablement cree une route. D'oCj i'asym&rie du mecanisme de NAT. 
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Les limites de ce mecanisme sont multiples et apparaissent de plus en 
plus manifestos avec la diversite des applications sur I'lnternet et la 
multiplication des r6seaux prives : aujourd'hui en effet, 1'utilisation des reseaux 
prives ne se limite plus aux entreprises, mais concerne aussi une grande 
5 partie du public, le plus souvent celui connects via PADSL 

Prenons I'exemple d'une intervention ^assistance. La plupart des 
terminaux informatiques sont aujourd'hui equipes d'un serveur HTTP 
embarque qui permet la configuration. On ne pourrai par exemple pas 
accepter aujourd'hui une assistance ou un technicien depuis le reseau public 
10 v6rifierait la configuration d'un equipement pris en defaut et sa correction par 
simple connexion HTTP. Au mieux, le technicien pourrait demander au client 
de rediriger un port de sa passerelle vers Tequipement en question en creant 
lui-meme une route, ce qui representerait une operation tout aussi infaisable 

■ 

pour le client que pourrait I'etre la correction de la configuration effectu6e 

15 parle client lui-meme. 

Les regies r§gissant le fonctionnement des pare-feu peuvent aller du 
plus simple au plus complique. Le plus simple est de tout ou de ne rien 
autoriser. Pour avoir une strategie de s6curit§ plus coherente, les pare-feu 
fonctionnent aujourd'hui en se basant sur le type d'applications. En autorisant 

20 une application £ aller sur I'lnternet, on autorise en fait les paquets a 
destination du port associ§ £ ce type d'application a aller sur I'lnternet (Port 
80 pour HTTP, 21 pour FTP). Certaines nouvelles applications utilisent une 
multitude de ports, souvent dynamiques. On peut citer par exemple les 
applications de jeux ou celles de telephonie et de visiophonie. Uattribution 

25 dynamique des ports ne permet pas de definir des r&gles ad§quates. On se 
retrouve dans ('obligation de laisser tous les paquets passer ou au mieux 
d'ouvrir une plage complete de ports, strategies insatisfaisantes du point de 
vue de la securita 

Aussi, le probleme technique ^ resoudre par Tobjet de la pr6sente 
30 invention est de proposer un systems de communication entre un premier 
terminal informatique dans un reseau IP priv6 et un deuxfeme terminal 
informatique dans un reseau IP public, comprenant un equipement de 

« 

frontiere de r6seau, qui permettrait de resoudre le probleme des connexions 
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entrantes vers un reseau priv6, et de simplifier, sans la com prom ettre, la 
strategie de security appliquee a la frontiere du reseau prive, avec une 
configuration minimale ou nulle des elements existants sur T6quipement de 
frontiere, passerelle et pare-feu. 

La solution au probleme technique pos6 consiste, selon la presente 
invention, en ce que ledit systeme de communication comprend egalement, 
dans le reseau IP prive, un systeme de mediation, associ6 audit premier 
terminal, apte & mettre a disposition dudit deuxieme terminal une interface IP, 
et, dans le reseau IP public, un serveur de controle apte & contrSler ledit 
systeme de mediation via un tunnel de communication traversant ledit 
Squipement de frontiere de r6seau. 

La description qui va suivre en regard des dessins annexes, donn§s a 
titre d'exemples non limitatifs, fera bien comprendre en quoi consiste 
I'invention et comment elle peut etre r§alisee. 

La figure 1 est un schema gendral tfun systeme de communication 
conforme a I'invention. 

La figure 2 est un schema d§taille du systeme de communication de la 
figure 1 . 

Sur la figure 1 est repr§sente un systeme de communication entre un 
premier terminal informatique 1 dans un reseau IP priv6 7 et un deuxi§me 
terminal informatique 5 dans un reseau IP public, ledit systeme comprenant 
un equipement 3 de frontiere de rSseau, du type passerelle et/ou pare-feu. Le 
systeme de communication de la figure 1 doit permettre de traverser cet 
6quipement et de rendre sa configuration simple, tout en conservant de 
bonnes performances. Le systeme est ind6pendant des protocoles au dessus 
de TCP (Transmission Control Protocol) et UDP (User Datagram Protocol). 
On peut I'utiliser pour tous les types duplications qui veulent resoudre 
efficacement le probleme de travers6e des passerelles et pare-feu. 

De mantere g§nerale, le terminal 5, via ['utilisation du serveur 4 de 
controle, et grace a la presence du systeme 2 de mediation sur le r6seau 
prive 7, doit pouvoir disposer de I'interface TCP/UDP/IP du systeme 2 de 
mediation pour rendre le service qu'il propose. Le systeme 2 de mediation met 
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ainsi a disposition du terminal 5 son interface TCP/UDP/IP via le serveur 4 de 
controle, 

A cette fin, on cree a travers la passerelle/pare-feu 3 un tunnel 6 de 
communication entre le systeme 2 de mediation et le serveur 4 de controle. 
5 Les 6lements 2 et 4 sont complement generiques et seul le terminal 

informatique a Intelligence du service rendu au terminal 1 du reseau prive 7. 

Pour communiquer avec le terminal IP externe 5, le terminal IP interne 1 
s'adressera au systeme 2 de nrtediation. De meme, le terminal IP externe 5 
s'adressera au serveur 4 de controle. Le tunnel 6 sera Stabli par le systeme 2 
io vers le serveur 4 vers un port unique et fixe, rSpondant ainsi aux regies 
g6n§rales de traversee du rrtecanisme NAT et des pare-feu. Cela permet de 
minimiser les impacts au niveau de la configuration du routeur et de g6rer 
efficacement les connexions des clients aux serveurs. 

Par la suite, on appellera le port unique et fixe du serveur 4 de controle 
15 "port de service". 

Par tunnel 6, on entend un canal TCP et aucun ou plusieurs canaux 
UDP, entre le systeme 2, par un port quelconque, et le serveur 4, par ledit port 
de service. 

Une description detaillSe du fonctionnement du systeme de 
20 communication conforme a Invention va maintenant etre presentee en regard 
de la figure 2. 

Afin de s'initialiser, le systeme 2 de mediation se connecte sur un port fix6 
du serveur 4 de controle via un canal TCP. II utilise cette connexion pour 
informer le serveur 4 de son etat ainsi que de son environnement. Ces 
25 informations peuvent aller de sa configuration dans le r6seau priv§ 7 (adresse 
IP, masque de sous-eseau ....) & la description du service qu'il veut utiliser, 
en passant par une authentification ou identification. 

Une fois P initialisation realis6e, les op6rations entre le systeme 2 et le 
serveur 4 seront de 3 types: 

30 • Commandes d'ouverture, de redirection, de connexion, de mise en 

ecoute et de fermeture de ports. 

• Relais de paquets et d'evenements. 

• Maintien des canaux. 
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Un protocole leger sera utilis6 entre le systeme 2 et le serveur 4 pour 
annoncer et decrire ces differentes operations. Seule la semantique de ce 
protocole sera presentee ici, la syntaxe 6tant laissee a la discretion des 

* 

r6alisateurs du service. 

5 

1. Commandes d'ouverture, de redirection et de fermeture de ports 

Les commandes d'ouverture, de redirection et de fermeture de ports sont 
faites par le serveur 4 au systeme 2 de mediation. 
• Ouverture; 

10 Le serveur 4 demande 1'ouverture d'un port en envoyant Padresse IP et 

le num§ro de port a ouvrir (ie systeme 2 de mediation peut etre sur une 
machine du r6seau local qui dispose de plusieurs adresses IP sur ce 
reseau), le type de service (TCP ou UDP), et importance accord£e au 
num6ro de port (on peut demander un num§ro de port souhaite mais non 

15 obligatoire, le premier port libre & partir du num6ro demande sera ainsi 

attribue. On peut au contraire demander un numero de port obligatoire). 

La r§ponse a la demande d'ouverture se fait par renvoi d'un identifiant 
du port ouvert et du num§ro de port attribue, ou d'un code d'erreur en cas 
d'echec. 

20 • Redirection: 

La redirection de ports repond & une contrainte particuli^re. 
Le canal de service presente plus haut est base sur TCP. Tel qu'ii est 
d6fini, il peut transmettre des paquets qui arrivent sur I'interface interne du 
systeme 2 de mediation en TCP ou UDP. 

25 En faisant transiter les paquets qui sont arriv§s au dessus d f UDP sur le 

canal TCP, on leur ajoute des caracteristiques particulieres. En effet, TCP 
est un protocole dit fiable par rapport a UDP, c'est-£-dire que les paquets 
transitant sur TCP sont acquittes par le receveur. Les paquets non 
acquittes sont reexpedtes par F6metteur. Ce m6canisme de fiabilit§ 

30 implique un delai. Certaines applications choisissent d'utiliser UDP pour 

eviter le d6lai induit par la fiabilite. Le m6canisme de redirection de ports a 
pour but de permettre a Tapplication mettant en ceuvre I'invention de 
garder UDP comme couche de transport sous-jacehte. 
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Le serveur 4 demande la redirection d'un port en envoyant I'adresse IP 
. et le numero de port £ rediriger (le systeme 2 peut etre sur une machine du 
reseau local qui dispose de plusieurs adresses IP sur ce r§seau), et 
I'importance accord6e au num6ro de port (on peut demander un numero 
5 de port souhaitS mais non obligatoire, le premier port libre a partir du 
num§ro demande sera ainsi attribue. On peut au contraire demander un 
numero de port obligatoire). 

La r6ponse £ la demande de redirection se fait par renvoi d'un 
identifiant du port redirig6 et du num6ro de port attribu§, ou d'un code 
io d'erreur en cas d'6chec. 

Une fois une redirection mise en place, tout paquet arrivant sur le port 
redirige sera systematiquement relaye vers le serveur 4 sur son port fixe, 
en utilisant UDP. 

• Connexion : 

15 Le serveur 4 demande au systeme 2 de mediation de connecter un port 

TCP pr§alablement ouvert, a une adresse IP et un port d'un systeme IP du 
reseau priv6 7. Le serveur 4 accompagnera sa demande de I'identifiant du 
port prealablement ouvert, ainsi que I'adresse IP et le port auquel il doit se 
connecter. 

20 La reponse a la demande de connexion se fait par renvoi d'un code 

* ■ 

cfacquittement ou d'un code d'erreur en cas d'echec. 

♦ Mise en ecoute: 

Les ports TCP sont de 2 types : 

o soit des ports serveurs ou de service : ce sont des ports qui 
25 acceptent des connexions d'autres ports, lis sont done en 

ecoute. C'est typiquement le cas des ports 80 des serveurs 
HTTP. 

o soit des ports clients ou ports de connexion : ce sont les ports 
qui vont aller se connecter aux ports serveurs. 
30 Lors def ouverture d'un port TCP (m6canisme decrit plus haut), ce port 

n'est pas encore specialise. II devient port client (systeme 2) des que le 
serveur 4 demande de le connecter a un autre port. 
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Pour specialiser un port TCP ouvert en port serveur, la partie serveur 
de Tinvention envoie a la partie cliente (systeme 2) une commande de 
rnise en ecoute en precisant I'identifiant du port ouvert concerne. 

La reponse a la demande de mise en 6coute se fait par renvoi d'un 
5 code d'acquittement ou d'un code d'erreur en cas d'6chec. 

• Fermeture : 

Le serveur 4 demande la fermeture d'un port en envoyant I'identifiant 
du port re?u lors de I'ouverture ou de la redirection. 

La reponse a la demande de fermeture se fait par renvoi d'un code 
10 d'acquittement ou d'un code d'erreur en cas d'6chec. 

2. Relais de paquets et d'evenements 

• Relais de paquets: 

Cette operation est bidirectionhelle. Le serveur 4 peut demander au 
is systeme 2 d'envoyer un paquet sur le reseau prive 7. II accompagnera 

cette demande de I'identifiant du port a utiliser pour emettre le paquet 
(identifiant regu lors de I'ouverture du port), de I'adresse IP et du numero 
de port destination et du paquet £ envoyer. 

Dans I'autre sens, le systeme 2 de mediation relayera un paquet qu'if a 
20 re?u sur un port ouvert prealablement par le serveur 4 en indiquant 

I'identifiant du port de reception, I'adresse IP et le numero de port 
d'§mission ainsi que le paquet re^u. 

• Relais d'evenements: 

Les 6v6nements relayes par le client (systdme 2) au serveur 4 sont des 
25 6v6nements sur les ports ouverts. Ces tenements sont : 

o Connexion d'un systeme IP du reseau interne 7 d un port 
serveur TCP ouvert (correspondent & la s§quence SYN, 
SYN/ACK, ACK). 

o Demande de fermeture (message TCP FIN) ou destruction 
30 (message TCP RST) d'une connexion TCP. 

3. Maintien des canaux 
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Sur i'ensemble des equipements reseau traverses par le tunnel 6 entre 
le client (systeme 2) et le serveur 4, des mecanismes de scrutation des 
routes actives peuvent exister. Ces mecanismes verifient la non 
obsolescence de routes, c'est-S-dire des 3 couples « adresse IP-port ». Si 
aucun paquet n'ayant pour coordonnSes source et destination ces couples 
ne traverse P6quipement 3 pendant un laps de temps (appele TTL pour 
Time To Live), la route sera d§truite. A titre d'exemple, cela empdchera 
ensuite un paquet venant du serveur 4 vers le client 2 de passer 
I'equipement 3. Le tunnel 6 est ainsi cass6. 

Pour 6viter ce probldme, le client 2 enverra sur les canaux ouverts vers 
le serveur 4 un paquet (dit de maintien de canal) avant Toccurrence du 
TTL du canal en question. 
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REVENDICATIONS 



1. Systeme de communication entre un premier terminal informatique (1) dans 
5 un reseau IP priv6 (7) et un deuxieme terminal informatique (5) dans un 

reseau IP public, comprenant un 6quipement (3) de fronttere de r6seau, 
caracteris6 en ce que ledit systeme de communication comprend 6galement, 
dans le >6seau IP priv§, un systeme (2) de mediation, associ6 audit premier 
terminal (1), apte a mettre a disposition dudit deuxteme terminal (5) une 
10 interface IP, et, dans le r6seau IP public, un serveur (4) de contrdle apte a 
controler ledit systeme (2) de rrtediation via un tunnel (6) de communication 
traversant ledit 6quipement (3) de frontfere de r6seau. 

2. Systeme de communication selon la revendication 1 , caracteris6 en ce que 
ladite interface IP est une interface TCP/UDP/IP. 

15 3. Systeme selon la revendication 2, caracteris6 en ce que ledit tunnel (6) de 
communication est un canal TCP apte a transmettre des paquets arrivant sur 
une interface interne du systeme (2) de m6diation en TCP ou UDP. 
4. Systeme selon Tune quelconque des revendications 1 a 3, caracterise en ce 
que le systeme (2) de irtediation est apte a relayer un paquet re?u sur un port 

20 ouvert pr6alablement par le serveur (4) de controle en indiquant un identifiant 
du port de reception, une adresse IP et un numero de port demission ainsi 
que le paquet refu. 



25 
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